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1.  Introduction 

The  open  system  approach  is  both  a  technical  approach  to  systems  engineering  and  a  preferred 
business  strategy  that  is  becoming  widely  applied  by  commercial  manufacturers  of  large  complex 
systems.  It  has  the  attention  of  DoD  management  who  have  mandated  its  use  by  DoD  systems 
developers.  Why?  Because  without  such  a  change  in  system  development  practice,  DoD  risks  being 
unable  to  maintain  continued  superior  combat  capability  affordably! 

Today,  legacy  weapons  systems  continue  to  be  developed  with  their  own,  often  unique  and 
frequently  closed,  infrastructures,  making  upgrading  or  modifying  them  over  their  expected  lifetimes  (20 
to  40  years)  both  problematic  and  expensive.  Also,  reduced  procurement  budgets  and  increased 
dominance  of  commercial  technology  cause  acquisition  managers  to  increasingly  rely  on  commercial 
markets  for  affordable  product  development  and  support.  So,  as  DoD’s  role  shifts  from  being  a 
technology  producer  to  being  a  technology  consumer,  it  relies  more  on  commercial  products  whose 
design  is  not  controlled  by  DoD  and  whose  lifetimes  are  much  shorter  and  more  volatile  than  the 
weapons  systems  they  support  (e.g.,  years  vs.  decades).  As  a  result,  acquisition  managers  risk  relying 
on  unique  products  provided  by  a  single  supplier  at  high  non-competitive  prices  and  with  little 
opportunity  for  technology  insertion  by  other  suppliers. 

This  paper  discusses  the  need  for  a  rigorous  systems  engineering  process  which  incorporates 
open  systems  concepts  and  principles  —  where  resulting  system  designs  more  readily  accommodate 
changing  technology  to  achieve  cost,  schedule,  and  performance  benefits  by  promoting  multiple  sources 
of  supply  and  technology  insertion. 
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2. 


The  Need  for  an  Open  Systems  Design  Approach 


An  open  systems  design  approach  can  allow  a  weapon  system  program  office  to  achieve  and 
maintain  combat  superiority  in  today’s  challenging  acquisition  environment.  This  approach  focuses  the 
design  process  on  lowering  the  entire  life-cycle  costs  (LCC)  of  weapon  systems  in  contrast  to  current 
practice  in  which  a  disproportionate  focus  is  placed  on  the  short-term  goal  of  having  the  lowest 
development  costs.  Figure  1  illustrates  that  72  percent  of  LCC  are  incurred  post-IOC  during  the  service 
lifetime  [1],  The  ability  of  the  open  systems  design  approach  to  improve  life-cycle  supportability  is 
becoming  an  even  more  important  issue  as  DoD  limits  the  number  of  new  weapon  systems 
procurements  and  extends  the  life  of  the  systems  currently  fielded. 


Figure  1.  Life  Cycle  Costs 


It  seems  clear  that  DoD  managers  should  concentrate  on  doing  things  in  systems  engineering 
and  development  that  will  decrease  costs  during  production  and  especially  during  the  operations  and 
support  (O&S)  phase.  An  open  systems  approach,  basing  the  weapon  system’s  design  on  open, 
commercially  supported  interface  standards  with  the  prospects  of  a  large  supplier  and  customer  base, 
focuses  the  systems  engineering  process  on  developing  system  designs  which  consider  life-cycle  support 
requirements  up  front  and  that  support  system  evolution  throughout  the  system’s  life. 

An  open  systems  approach  also  mitigates  the  increased  risks  of  obsolescence  due  to  shortened 
technology  cycle  time.  Obsolescence  risks  are  significant  because  technology  cycle  time,  sometimes  on 
the  order  of  months,  far  outpace  weapon  system  development  cycle  time,  typically  8  to  15  years.  By 
the  time  a  system  is  fielded,  supporting  technologies  are  often  outdated  —  the  US.  military  cannot  afford 
to  be  3  or  4  technological  generations  behind  what  is  available  to  the  commercial  market.  Open 
systems  designs,  using  commercially-supported  interface  standards  permitting  upgrade  at  a  relatively 
low  cost,  specifically  address  issues  of  affordability  and  supportability  associated  with  long  lived  system 
by  facilitating  evolutionary  upgrade  with  new  technology.  Generally,  this  results  in  superior  combat 
capability  over  the  total  system  life-cycle,  usually  at  a  lower  cost  to  the  government. 


Another  reason  that  open  systems  have  become  so  attractive  is  that  DoD  is  no  longer  the 
dominant  force  in  the  market  place  and  DoD’s  procurement  budget  has  been  drastically  reduced.  DoD 
no  longer  has  the  luxury  of  technology  dominance,  funded  by  seemingly  unlimited  budgets.  In  prior 
decades,  DoD  requirements  drove  development  of  new  products  and  new  technology.  In  the  today’s 
environment  the  opposite  is  true;  commercial  demand  drives  product  and  technology  development. 
However,  DoD  can  now  take  advantage  of  commercial  innovation,  research  and  development  to  drive 
down  its  cost  of  developing,  acquiring  and  maintaining  weapon  systems,  leveraging  the  commercial 
investment  to  make  the  most  of  available  and  shrinking  defense  funds.  An  open  systems  approach, 
using  open  interfaces  supported  by  commercial  and  non-developmental  components,  can  substantially 
facilitate  this  leveraging. 

The  bottom-line  issue  is  not  only  cost:  the  lives  of  our  servicemen  may  depend  on  shortened 
technology  insertion  cycle  times.  In  a  global  market,  everyone,  including  our  potential  adversaries,  will 
gain  increasing  access  to  the  same  commercial  technology  base.  The  military  advantage  goes  to  the 
nation  that  has  the  best  cycle  time  to  capture  the  very  best  commercially  available  technologies, 
incorporate  them  in  weapon  systems,  and  get  them  fielded  first.  Moreover,  since  coalition  operations 
with  our  allies  place  a  high  premium  on  interoperability,  it  is  essential  that  our  systems  be  compatible 
and  capable  of  being  sustained  through  a  common  logistics  support  structure.  Open  systems 
specifications  and  standards  promote  standard  interfaces  and  interoperability  with  our  friends  and  allies. 

Each  of  these  many  issues  will  continue  to  substantively  challenge  past  DoD  acquisition 
practices  throughout  the  foreseeable  future.  As  a  result,  DoD  finds  itself  with  few  alternatives  but  to 
drastically  alter  the  way  it  develops,  produces  and  supports  its  weapon  systems.  It  is  neither 
economically  nor  technologically  feasible  to  continue  traditional  closed  design  approaches.  DoD  is 
increasingly  compelled  to  move  towards  a  more  open  weapon  systems  design  alternative. 


3.  Open  Systems  Design  Concepts 


Simply  put,  the  concept  of  open  systems  is  a  common  sense  approach  that  has  substantial 
promise  as  an  approach  to  meet  DoD’s  continuing  need  to  support  systems  over  increasingly  long  life 
cycles  in  an  environment  of  decreasing  resources.  In  a  time  when  the  development  of  a  complex  system 
can  span  several  generations  of  the  faster  moving  technologies,  open  system  architectures  offer  the 
tantalizing  prospect  of  facilitating  performance  upgrades  at  affordable  costs  for  the  life  cycle  of  the 
system.  The  potential  and  practice  of  open  systems  design  as  an  emerging  topic  within  the  systems 
engineering  discipline  has  now  been  with  us  for  several  years.  In  addition,  the  use  of  open  systems  has 
received  the  attention  and  support  of  the  highest  levels  of  DoD.  In  1996,  DoD  issued  a  revised 
directive  DoD  5000.2-R  that  instructs  program  managers  to  employ  open  systems  as  a  design 
consideration  in  defense  systems  engineering  [2]  .  The  systems  engineering  process,  with  specific 
reference  to  the  consideration  of  open  systems  designs,  is  integral  to  achieving  the  benefits  of  open 
systems  designs. 

While  there  are  many  definitions  of  open  systems  [3],  most  have  a  few  characteristics  in 
common.  Open  systems  are  those  that  can  be  supported  by  the  marketplace,  rather  than  being 
supported  by  a  single  (or  limited)  set  of  suppliers,  due  to  the  unique  aspects  of  the  design  chosen.  Open 


systems  architectures  are  achieved  by  having  the  design  focus  on  commonly  used  and  widely  supported 
interface  standards.  One  might  think  in  terms  of  the  axle- wheel-tire  interfaces  employed  on  commercial 
cars.  By  adhering  to  common  standards  at  the  interfaces,  the  consumer  is  able  to  buy  tires  from  a 
multitude  of  suppliers,  rather  than  being  forced  to  buy  from  a  single  source,  as  might  be  the  case  if  the 
interface  characteristics  were  unique  to  a  single  supplier.  This  ensures  costs  and  quality  that  are 
controlled  by  the  forces  of  competition  in  the  marketplace.  Furthermore,  the  continued  support  of  the 
system  is  not  subject  to  the  risks  associated  with  having  a  single  supplier  go  out  of  business  or  cease 
supporting  the  standard.  As  the  technologies  associated  with  tires  change  with  time,  the  customer  can 
continue  to  upgrade  and  support  his  vehicle  with  tires  that  are  built  to  the  accepted  industry  standard 
(e.g.,  conventional  sidewall  bias-ply  technology  tires  to  steel-belted  radial-ply  technology  tires). 

However,  despite  all  the  high-level  attention  on  open  systems,  DoD  program  managers  must 
exercise  some  care  and  judgment  in  their  application  of  the  open  systems  approach.  It  does  not 
represent  a  new  approach  that  replaces  and  makes  obsolete  previous  approaches  to  engineering 
complex  systems.  Moreover,  managers  should  not  simply  implement  an  open  standard  without  careful 
consideration  of  where  (in  the  system  hierarchy)  it  makes  sense  to  impose  standards  nor  should  they 
simply  grasp  for  a  commercial  item  (Cl)  solution,  whether  or  not  the  solution  leads  to  the  benefits  of 
open  systems  architectures.  Such  actions  may  encourage  program  managers  to  declare  that  they  are 
achieving  open  systems  attributes,  whether  or  not  the  system  design  is  well  thought  out  to  take  full 
advantage  of  the  benefits  that  the  open  systems  approach  offers.  This  may  give  the  appearance  of 
achieving  open  systems  architectures  but,  in  fact,  such  short-sighted  decisions  work  against  the  long 
term  viability  of  the  system.  The  open  system  concept  does  not  replace  the  need  for  following  a 
rigorous  systems  engineering  process  but,  in  fact,  requires  more  rigor  to  ensure  that  open  systems 
benefits  are  achieved. 


4.  Open  Systems  Applied  Within  the  Systems  Engineering  Process 


Systems  engineering  is  fundamentally  a  problem  solving  process  that  translates  needs  and 
requirements  as  inputs  into  designs  and  products  as  outputs.  The  systems  engineering  process  typically 
starts  with  problem  definition  as  requirements  are  analyzed.  Alternative  solutions  or  system 
architectures  are  developed,  usually  initially  through  techniques  such  as  functional  analysis  and  data  flow 
analysis.  Alternative  physical  designs  are  then  developed  to  satisfy  the  functional  or  data  flows.  Trade 
studies  and  risk  analyses  are  applied  to  select  a  preferred  design  solution,  and  that  solution  is  verified 
against  the  original  requirements. 

This  process,  properly  applied,  results  in  a  flow  down  of  requirements  from  the  system  level  to 
the  items  below  system  level.  As  these  requirements  are  flowed  down,  the  design  requirements  for  the 
items  below  system  level  are  defined.  Once  these  lower  level  design  requirements  are  finalized,  the 
design  process  proceeds  to  completion.  The  result  is  a  design  which  associates  physical  entities  with  the 
functions  that  the  system  must  perform,  and  is  consistent  with  the  levels  of  performance  required  and 
with  the  interfaces  specified. 

This  process,  applied  without  constraints,  will  lead  to  the  design  of  a  system  in  which  every  item 
is  optimized  to  the  requirements  in  terms  of  function,  performance,  and  interface.  Too  often,  the  results 
in  DoD  have  been  systems  that  are  unique  in  their  designs,  which  perform  their  missions  quite  well,  but 


which  require  unique  equipment  and  parts  to  support  them,  and  which  can  be  supported  only  by  a 
limited  set  of  suppliers.  This  has  historically  been  a  prescription  for  “closed”  systems  that  are  both 
difficult  and  costly  to  support. 

The  challenge  in  DoD  is  to  design  systems  to  take  advantage  of  open  systems  concepts  where 
that  makes  sense,  while  continuing  to  meet  the  needs  and  requirements  of  operational  forces.  The 
solution  is  not  to  suddenly  abandon  good  systems  engineering  and  simply  impose  standard  interfaces  at 
some  point  in  the  system,  nor  is  the  answer  likely  to  be  found  in  indiscriminately  importing  Cl  solutions 
into  the  system  architecture.  Rather,  the  real  answer  is  to  be  found  in  performing  good  systems 
engineering  while,  as  DoD  dictates,  employing  open  systems  as  a  design  consideration  from  the  outset. 
The  challenge,  then,  is  to  integrate  systems  engineering  and  open  systems  design. 

To  this  end,  the  use  of  architectures  in  DoD  has  become  a  preferred  management  approach  for 
implementing  an  open  systems  approach  [4].  DoD  has  implemented  this  concept  by  defining  an 
interrelated  set  of  architectures:  Operational,  System,  and  Technical  (illustrated  in  Figure  2).  Basically, 
the  Operational  Architecture  specifies  the  “user  requirements”  which  are  used  as  inputs  to  the  systems 
engineering  process  to  eventually  build  the  weapon  system.  The  Technical  Architecture  and  Product 
Lines  constrain  the  system’s  design  during  the  system  engineering  process.  The  System  Architecture 
emerges  as  an  output  and  is  constructed  to  satisfy  Operational  Architecture  requirements  within  the  rules 
and  standards  defined  in  the  Technical  Architecture.  Technical  architectures  are  particularly  important  to 
the  systems  engineering  process  because  they  provide  the  building  codes  for  implementing  systems  upon 
which  engineering  specifications  are  based,  common  building  blocks  are  built,  and  product  lines  are 
developed.  Note  that  while,  each  of  these  architectures  by  themselves  build  nothing,  together  they 
provide  a  management  tool  which  facilitates  evolutionary  acquisition  by  supporting  insertion  of  new 
technology,  component  reuse,  improved  weapon  systems  interoperability  and  the  accommodation  of 
evolving  user  requirements. 


Figure  2.  Architectures  and  the  Systems  Engineering  Process 


Who  chooses  the  technical  architecture?  Does  the  government  choose  the  architecture;  does 
industry  choose  the  architecture  or  is  the  architecture  chosen  in  concert?  The  government  may  specify 
key  performance  attributes  of  system  building  blocks  including  internal  interface  standards.  However, 


doing  so  without  adequate  input  from  industry  stifles  innovation,  limits  performance  and  increases  cost 
by  attempting  to  substitute  our  wisdom  for  that  of  the  designer.  If,  on  the  other  hand,  we  provide  no 
guidance,  we  may  encourage  development  of  proprietary  architectures,  interfaces  and  components. 

That  would  leave  DoD  in  a  position  where  it  must  maintain  and  modify  a  unique  product  with  a  single 
supplier  at  a  high,  non-competitive  price.  Each  program  must  chose  a  path  between  these  two 
extremes.  A  desirable  situation  is  for  there  to  be  a  consensus  among  potential  prime  contractors  and 
their  key  suppliers  on  application  of  widely  accepted  standards. 

Using  an  open  systems  approach  to  the  systems  engineering  process  helps  achieve  an  integrated 
design  solution  which  is  resilient  to  changes  in  technology  throughout  the  life  of  the  system.  Open 
systems  (engineering)  achieves  this  resiliency  in  “life-cycle  supportability”  by  engineering  systems 
according  to  the  following  principles  and  practices  (illustrated  in  Figure  3): 


Figure  3.  Open  Systems  Analysis  for  Integrated  Design  Solution 


•  Identify  as  critical  the  interfaces  to  subsystems  or  components  which  are  likely  to  change 
due  to  their  dependence  on  rapidly  evolving  technology,  are  likely  to  have  increasing 
requirements,  have  high  replacement  frequency  or  have  high  costs.  Such  components 
present  both  the  highest  obsolescence  risks  and  the  greatest  opportunity  for  future 
technology  insertion. 

•  Use  open  standards  for  these  critical  interfaces  that  are  supported  by  the  broader 
community, ,  are  considerate  of  life-cycle  support  requirements,  permit  evolution  with 
advances  in  technology,  and  support  technology  insertion. 

•  Use  a  modular  design  approach  combined  with  well  defined  standards-based  interfaces 
among  modules  to  isolate  the  effects  of  change  in  evolving  systems,  serving  to  reduce  the 
need  for  redesign  as  the  system  is  upgraded. 

•  Identify  the  lowest  level  at  which  the  government  maintains  control  over  the  interface 
standard,  and  anticipate  how  this  level  may  change  over  time.  Below  this  level  the 
contractor  is  permitted  to  use  its  best,  perhaps  proprietary,  practices  to  improve  or 
discriminate  its  product  in  the  marketplace. 

•  Verify  all  performance  requirements  and  reevaluate  their  stringency.  Reallocate 
requirements  as  necessary  to  permit  the  wider  use  of  open  standards  throughout  the  system. 


•  Implement  consistent  conformance  management  practices  to  ensure  that  products  procured 
for  the  system  conform  to  the  established  profile  so  as  to  prevent  being  limited  to  one 
supplier  who  might  unilaterally  extend  that  interface. 


The  key  to  achieving  the  benefits  of  open  systems  designs  lies  in  making  open  systems  an 
integral  part  of  the  classic  systems  engineering  process  and  in  applying  open  systems  at  all  stages  of  the 
product  life  cycle.  The  open  systems  approach  to  design  will  never  replace  or  make  obsolete  that 
process  —  if  anything,  it  demands  that  the  process  be  even  more  rigorously  applied.  As  is  illustrated  in 
Figure  4,  each  of  the  major  aspects  of  the  systems  engineering  process  must  include  consideration  of 
open  systems  design  concepts  and  principles: 
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-  Decision  Data  Base 

-  System/Configuration  Item 
Architecture 

-  Specifications  &  Baselines 


Figure  4.  Integrating  Open  Systems  and  the  Systems  Engineering  Process 


Requirements  analysis  must  emphasize  the  balancing  of  business  goals  (costs,  common  use, 
life  cycle  supportability,  etc.)  with  technical  goals  (functionality,  performance,  interfaces,  and  other 
constraints).  As  the  systems  engineering  process  iterates,  the  requirements  analysis  step  is  revisited  to 
consider  cost-performance  tradeoffs  to  meet  most  performance  objectives  while  achieving  as  large  as 
possible  reductions  in  life-cycle  costs.  The  stringency  of  requirements  is  reevaluated  to  consider  the  use 
of  open  standards  for  interfaces  as  performance  requirements  are  balanced  (weighed)  against  business 
requirements.  To  do  this,  engineers  need  to  be  better  trained  to  incorporate  life  cycle  cost  in  design  and 
provided  tools  which  allow  them  to  rapidly  assess  life  cycle  cost  impacts.  Under  any  circumstances, 
users  have  a  requirement  for  systems  that  are  supportable  and  affordable,  and  these  requirements 
demand  that  one  consider  open  architectures  as  system  elements  are  defined. 

Functional  analysis  and  allocation  must  define  an  architecture  which  provides  a  framework 
for  identifying  interfaces  critical  to  achieving  system  business  and  technical  performance  goals. 
Requirements  should  be  allocated  with  a  view  toward  achieving  functional  modularity.  Functional 


modularity  can  facilitate  physical  modularity  and  the  use  of  open  interfaces  to  support  system  evolution 
goals.  As  the  systems  engineering  process  iterates,  this  step  is  revisited  to  allocate  functionality  so  as  to 
modularize  those  components  or  subsystems  which  are  dependent  on  rapidly  evolving  technology,  have 
high  replacement  frequency  or  are  high  costs  and  to  reallocate  performance  or  business  requirements  as 
necessary  to  allow  for  the  use  of  open  interface  standards  during  synthesis. 

Synthesis  and  design  should  continue  the  search  for  alternative  system  architectures  that  will 
satisfy  requirements.  To  be  effective,  good  design  synthesis  demands  an  iterative  approach  that  involves 
revisiting  the  functional  allocations  and  developing  alternative  physical  solutions  until  a  balanced  design 
(in  terms  of  cost,  performance,  and  risk)  is  achieved.  Modularity  should  be  used  in  system  design 
where  interfaces  between  modules  are  based  on  open,  widely-supported  interface  standards. 

Modularity  should  be  based  on  well-defined  interfaces  to  isolate  components  that  are  likely  to  change 
over  time  (e.g.,  dependent  on  rapidly  evolving  technology,  have  high  replacement  frequency)  or  are  high 
costs  since  these  components  present  the  highest  obsolescence  risks  and  the  greatest  opportunity  for 
future  technology  insertion.  Well-defined  interfaces  are  used  to  decouple  system  components  and  define 
firewalls  to  contain  evolution  of  lower  level  component  upgrades  and  modifications,  thereby  minirnizing 
future  redesign,  and  possibly  retesting,  when  components  are  upgraded.  In  addition,  physical 
modularity  should  be  aligned  with  functional  partitioning  to  facilitate  the  replacement  of  specific 
subsystems  and  components  without  impacting  others. 

Design  iteration  should  sequentially  reconsider  the  allocations  of  function  and  performance 
that  define  the  design  requirements  for  each  system  component  with  the  objective  of  achieving  user 
(customer)  requirements  within  an  optimal  open  systems  solution.  From  an  open  systems  perspective,  if 
this  sequential  iteration  is  stopped  as  soon  as  the  first  acceptable  technical  solution  is  achieved,  there 
are  two  probable  results:  either  the  solution  will  be  shown  to  (1)  require  unique  designs  that  require  new 
development,  or  (2)  an  open  solution,  if  imposed  at  this  point,  will  likely  not  meet  all  the  requirements  of 
the  user.  However,  in  most  cases,  a  final  design  can  almost  certainly  be  developed  that  results  in 
system  architectures  that  include  some  items  that  are  “open”  and  other  elements  that  are  not.  Although 
open  designs  are  the  objective,  it  is  neither  necessary  nor  in  some  cases  even  possible  that  every 
element  or  item  of  most  complex  systems  be  totally  open. 

Systems  analysis  and  control  must  include  conformance  management  incorporating  both 
implementation  and  applications  conformance  testing.  The  selected  conformance  approach  must  be 
fully  defined  and  documented  so  that  it  is  understood  by  all  parties.  The  degree  to  which  open  systems 
benefits  can  be  achieved  will  depend  largely  on  how  well  the  product  design  conforms  to  selected 
standards.  Completely  defined  interface  profiles  will  allow  vendors  to  build  standards-based 
components  and  allow  users  to  design  systems  to  use  standards-based  components.  In  all  cases, 
candidate  components  should  be  tested  against  detailed  system  profiles  to  ensure  that  components 
conform  to  profiles. 


5.  Open  System  Design  Challenges 


The  open  approach  to  system  design  offers  considerable  benefits,  already  discussed,  in  terms  of 
life  cycle  support,  affordability  and  timely  technology  insertion.  The  approach  also  carries  with  it  some 


substantial  differences  in  the  way  that  systems  will  be  managed  and  supported.  Since  by  its  nature  open 
systems  designs  will  involve  increased  use  of  commercial  and  non-developmental  items  in  systems 
architectures,  the  government  will  necessarily  have  to  plan  for  significant  differences  in  the  way  systems 
are  managed  from  a  technical  perspective.  These  differences  cut  across  almost  every  aspect  of 
engineering  management,  and  while  space  prohibits  an  exhaustive  treatment,  examples  include  the 
following: 

•  Standards  based  architectures  lessen  the  degree  of  control  that  DoD  can  expect  to  exert. 
Changes,  fixes,  and  updates  will  likely  be  under  the  vendor’s  control.  This  can  have  a 
significant  impact  on  system  support. 

•  Standards  based  elements  of  the  architecture  are  likely  to  be  faster  and  cheaper  to  acquire 
than  a  comparable  developmental  item  but  may  take  more  time  to  integrate  and  test. 

•  Standards  selection  is  risky.  Acquisition  will  require  substantially  more  knowledge  of  the 
current  state  of  the  art  and  the  marketplace  on  the  part  of  the  government. 

•  Standards  evolve  with  time.  It  is  difficult  to  project  the  extent  to  which  a  given  standard  will 
endure.  It’s  equally  challenging  to  determine  when  to  move  from  one  standard  to  the  next. 

•  Standards  based  architectures  tend  to  change  the  focus  of  systems  engineering  from  design 
to  integration.  The  challenge  is  to  achieve  performance  requirements  without  detailed  control 
over  the  component  design  specification. 

•  An  item,  once  integrated,  may  affect  other  system  parameters.  Commercial  and  NDI  items 
make  testing  an  on-going  and  continuing  activity  to  verify  that  items  can  integrate 
successfully  into  systems. 

•  The  use  of  commercial  and  NDI  requires  that  support  concepts  be  developed  early  in  the 
acquisition  cycle. 


While  this  is  hardly  an  exhaustive  fist,  it  makes  the  point  that  open  systems  engineering 
introduces  new  issues  into  the  management  of  the  technical  aspects  of  programs.  There  are  many 
potential  benefits,  but,  likewise,  there  are  challenges  and  problems  that  the  manager  must  be  alert  to 
anticipate  and  overcome. 


6.  Summary 


The  objective  of  open  systems  acquisitions  is  to  provide  the  warfighter  the  most  effective 
weapon  systems  possible.  An  open  systems  approach  to  systems  engineering  facilitates  this  throughout 
the  life  of  the  system.  Open  systems  designs  provide  an  opportunity  to  achieve  affordable  designs 
which  can  more  readily  accommodate  changing  technology  while  promoting  multiple  sources  of  supply; 
however,  to  achieve  good  open  systems  designs  first  demands  that  a  disciplined  systems  engineering 
approach  be  taken  to  defining  the  appropriate  elements  in  the  system  to  be  opened. 


Most  systems  will  not  be  completely  open  in  their  architectures,  but  a  well-engineered  design 
will  result  in  a  design  strategy  that  takes  maximum  advantage  of  the  benefits  available  from  opening  the 
design.  Associated  with  an  open  approach  is  the  need  to  focus  on  and  manage  the  interfaces  between 
open  system  elements  and  other  elements  of  the  system.  Choosing  well-known  and  accepted  industry 
standards  and  applying  them  in  a  controlled  manner  will  go  far  toward  achieving  the  desired  results. 
Overall,  the  system  architecture  resulting  from  a  system  engineering  process  should  be  linked  to  a 
business  case  analysis.  Architecture  decisions  should  be  traceable  to  performance,  life-cycle  cost, 
schedule,  and  risk.  The  alternatives  for  support,  maintenance  and  upgrade  should  be  evaluated. 

For  maximum  benefit,  an  open  systems  approach  should  focus  on  planned  use  of  designs  across 
a  system  or  domain.  As  designs  are  opened,  managers  must  be  aware  of  the  fact  that  support  and 
acquisition  strategies  will  necessarily  be  impacted.  These  impacts  must  be  anticipated  and  planned  for 
from  the  outset  during  system  design. 


More  open  systems  information  and  reference  materials  are  available  on  the  Open  Systems  Joint 
Task  Force  home  page  on  the  Worldwide  Web  at  http://www.acq.osd.mil/osjtf 
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